1. Field of the Invention
This invention relates generally to the field of communication systems and, more particularly, to session security protocol for a wireless communication system.
2. Description of the Related Art
Evolution-Data Optimized (EVDO) is a telecommunications standard for the wireless transmission of data through radio signals, typically for broadband Internet access. The EVDO protocol is a member of the CDMA2000 family of standards. The CDMA2000 family of standards are defined in “CDMA2000 High Rate Packet Data Air Interface Specification,” 3GPP2 C.S0024-B, Version 2.0, March 2007 (referred to herein as “3GGP2 C.S0024-B v2.0”), the teachings of which are incorporated herein by reference in their entirety.
FIG. 1 is a block diagram of a portion of a typical CDMA network 100. Access network 102 controls one or more base transceiver stations (BTSs) 104. Access terminal 106 communicates wirelessly with BTSs 104.
Access network 102, BTSs 104, and access terminal 106 utilize a time value known as the CDMA system time. Typically, BTS 104 and access network 102 use the time from the global positioning system (GPS) to generate their CDMA system time. Access terminal 106 typically gets its CDMA system time value from BTS 104 via an over-the-air broadcast message.
Communications between access network 102 and access terminal 106 is organized into several channels, e.g., traffic channel, access channel. The traffic channel carries rate-paying data, e.g., a communication between the access terminal and another access terminal. The access channel is used for communications between access terminal 106 and access network 102 when a traffic channel is not in use. The access channel is used primarily for call setup, i.e., authentication of the terminal and assignment of a traffic channel.
Communications over a channel are in the form of packets. A packet typically comprises a header, a payload, and a trailer. Packets are processed as they travel from source to destination, e.g., encapsulated/de-encapsulated. The CDMA2000 family of standards defines the processing of packets using a seven-layer model.
FIG. 2 is a diagram of the seven-layer model 200 used in CDMA2000. When a packet is sent by a source, the packet starts at application layer 214, and is processed by stream layer 212, session layer 210, connection layer 208, security layer 206, medium access control (MAC) layer 204, and physical layer 202. When a packet is received by a destination, the packet traverses the same seven layers, beginning with physical layer 202, and ending with application layer 214.
Security layer 206 performs several security-related functions, including the encryption and decryption of packets, and the authentication of packets. Security layer 206 utilizes four protocols: (i) the key-exchange protocol, (ii) the authentication protocol, (iii) the encryption protocol, and (iv) the security protocol. Three of the four security-layer protocols are important to this discussion: the security, key-exchange, and authentication protocols.
Generic Security Protocol
Two security-protocol variants are specified in 3GGP2 C.S0024-B v2.0: the default security protocol (section 8.3) and the generic security protocol (section 8.4). The default security protocol does not provide any services, but merely transfers packets between the authentication protocol and the MAC layer.
The generic security protocol's function is to generate crypto-synchronization (cryptosync) values for use by the other security-layer protocols. When a packet is being processed for transmission, the generic security protocol calculates cryptosync values based on the current CDMA system time. When a received packet is being processed, the generic security protocol calculates cryptosync values based on (i) the current CDMA system time and (ii) the information provided in the generic security protocol header of the received packet.
A cryptosync is a changing, common, external factor to an encryption process that causes the ciphertext for a particular plaintext to change with time. A common encryption process is the SHA-1 Secure Hash Algorithm, defined in Federal Information Processing document FIPS 180, the teachings of which are hereby incorporated by reference in their entirety. SHA-1 is a one-way function that takes a given plaintext and computes a 160-bit, nearly-unique ciphertext, i.e., hash, of that plaintext, where it is computationally impractical to derive the plaintext from its hash.
One typical use of SHA-1 is authentication. For example, assume that nodes A and B share a unique, secret key. If node A wants to prove to node B that it is in fact node A without broadcasting the plaintext of its secret key, node A can create an SHA-1 hash of its copy of the secret key and send it to node B. Node A is the initiator. Node B then creates an SHA-1 hash of its copy of the unique key, and compares the two hashes. Node B is the responder. If the hashes match, then the initiator, i.e., node A, is authenticated.
SHA-1 will always generate the same hash for the same specific plaintext. Therefore, if node C intercepts the hash sent from node A to node B, node C can use that hash to masquerade as node A to node B. This is known as a replay attack. To prevent replay attacks, a cryptosync is typically included in the plaintext. For example, node A and node B have synchronized clocks which increment every second. Node A concatenates its copy of the secret key with the clock time (the cryptosync) to yield a plaintext. Thus, the plaintext changes every second, and, consequently, the computed SHA-1 hash of that plaintext will change every second.
Node A sends its computed SHA-1 hash to node B. Node B concatenates its copy of the secret key with its clock time to create a plaintext, and compares the hash of that plaintext to the hash it received. If the hashes match, then the sender is authenticated as node A. Node C has at most a second in which to intercept node A's sent hash and pass itself off as node A. Otherwise, node B's clock will increment, and the hashes will not match.
A system that uses clock cryptosyncs, e.g., CDMA2000, typically makes allowance for a specified discrepancy between initiator and responder cryptosyncs. The specified discrepancy typically takes into account (i) the maximum computation and transmission delay and (ii) the maximum synchronization error.
Computation and transmission delay CTDelay is the absolute-time duration between (i) when the initiator computes its cryptosync and (ii) when the responder computes its cryptosync. CTDelay includes all the time required to, e.g., calculate the hash, further process the packet for transmission, transmit the packet, process the received packet for delivery to the security layer, etc.
Synchronization error is the discrepancy between the sender's clock and the receiver's clock. Thus, if a system has a maximum possible CTDelay of two seconds, and a maximum possible synchronization error of one second, then allowance is typically made for the cryptosyncs to differ by at least three seconds and still be considered equal.
In order to make this allowance, the CDMA generic security protocol calculates two cryptosync values: Cryptosync and CryptosyncShort. Cryptosync is the 64-bit CDMA system time of the device computing Cryptosync, in units of 80 ms. CryptosynchShort is the 16 least-significant digits of Cryptosync. As is discussed in greater detail below, the CDMA system uses these two values to calculate the responder's Cryptosync, i.e., Cryptosync(RR), such that Cryptosync(RR) will be equal to the initiator's Cryptosync, i.e., Cryptosync(IR), as long as Cryptosync(IR) is (i) no greater (later) than the system time of the receiver at the moment of Cryptosync(RR) calculation, and (ii) no more than 1.45 hours less (earlier) than the system time of the receiver at the moment of Cryptosync(RR) calculation.
SHA-1 Authentication Protocol
The authentication protocol comprises two variants: the default authentication protocol and the SHA-1 authentication protocol. The default authentication protocol is a null protocol, providing no services and simply relaying, unaltered, any packets which it receives.
The SHA-1 authentication protocol (3GPP2 C.S0024-B v2.0, section 8.8) defines a procedure (the access-channel authentication procedure) for authenticating an access-channel, MAC-layer packet by creating a message digest (i.e., an SHA-1 hash) of the data within the packet, and sending the message digest along with the packet data.
The SHA-1 authentication protocol is initiated by the access terminal, and thus the access terminal is referred to as the initiator, abbreviated IR. Likewise, the access network is referred to as the responder, abbreviated RR.
FIG. 3 is a flowchart of conventional access-channel authentication procedure 300. Processing begins at step 302 and continues to step 304 where the access terminal generates two values: Cryptosync(IR) and CryptosyncShort(IR). Specifically, procedure 300 gets these values from the generic security protocol. The generic security protocol generates these two values according to the following Equations (1) and (2):Cryptosync(IR)=SystemTime(IR)  (1)CryptosyncShort(IR)=Cryptosync(IR)[15:0]  (2)where SystemTime(IR) is the 64-bit CDMA system time of the access terminal.
Next, at step 306, the access terminal creates a plaintext, i.e., the IR message bits, from several inputs, including (i) a secret session key SKey shared by the access terminal and access network, and (ii) Cryptosync(IR).
Next, at step 308, the access terminal creates a 160-bit SHA-1 hash from the IR message bits, and stores the 64 least-significant bits of the hash as the IR hash.
Next, at step 310, a packet is sent to the access network containing, inter alia, (i) the 64-bit IR hash (i.e., the access-channel packet-authentication code (ACPAC)) and (ii) CryptosynchShort(IR).
Next, at step 312, the access network receives the packet send by the access terminal, and extracts the IR hash and CryptosynchShort(IR).
Next, at step 314, procedure 300 asks the generic security protocol to generate Cryptosync(RR), which the generic security protocol does according to the following Equation (3):
                              Cryptosync          ⁡                      (            RR            )                          =                              (                                                                                                      SystemTime                      ⁡                                              (                        RR                        )                                                              -                                                                                                                    (                                                                  (                                                                                                            SystemTime                              ⁡                                                              (                                RR                                )                                                                                      ⁡                                                          [                                                              15                                ⁢                                                                  :                                                                ⁢                                0                                                            ]                                                                                -                                                      CryptosyncShort                            ⁡                                                          (                              IR                              )                                                                                                      )                                            ⁢                      mod                      ⁢                                                                                          ⁢                                              2                        16                                                              )                                                                        )                    ⁢          mod          ⁢                                          ⁢                      2            64                                              (        3        )            where SystemTime(RR) is the 64-bit CDMA system time of the access network.
The net effect of Equation (3) is that Cryptosync(RR) will be set equal to Cryptosync(IR) as long as Cryptosync(IR) is (i) no greater than SystemTime(RR) and (ii) no more than 216 (or 65,536) less than SystemTime(RR). Stated another way, Equation (3) will set the Cryptosync(RR) equal to Cryptosync(IR) as long as Cryptosync(IR) is (i) no later than SystemTime(RR) and (ii) no earlier than SystemTime(RR) less 65,536×80 ms, or 1.45 hours. If either of these conditions is violated, then procedure 300 will fail. These two conditions are called the cryptosync constraints.
Next, at step 316, the access network creates a plaintext, i.e., the RR message bits, from several inputs, including (i) a secret session key SKey shared by the access terminal and access network and (ii) Cryptosync(RR).
Next, at step 318, the access network creates a 160-bit SHA-1 hash from the RR message bits, and sets the RR hash equal to the 64 least-significant bits of the calculated SHA-1 hash.
Next, at step 320, the access network compares the IR hash to the RR hash. If the two hashes match, then procedure 300 results in success (i.e., the access-channel packet is authenticated and the payload of the access-channel packet is forwarded to the encryption protocol); otherwise, procedure 300 results in failure (i.e., the access-channel packet is not authenticated and is dropped).
DH Key-Exchange Procedure
There exist two variants of the key-exchange protocol: a default key-exchange protocol and a Diffie-Hellman (DH) key-exchange protocol. The default key-exchange protocol is null, i.e., it performs no services.
The DH key-exchange protocol, defined in section 8.6 of 3GPP2 C.S0024-B v2.0, specifies a procedure, i.e., the DH key-exchange procedure, whereby the access network and the access terminal calculate a shared, secret key SKey that will be used for subsequent authentication and encryption. The key-exchange procedure is typically performed when the access terminal wishes to establish a new session with the access network, e.g., after the access terminal is turned on.
The DH key-exchange procedure comprises two sequential sub-procedures. In the first sub-procedure, the access terminal and the access network each calculate SKey. Specifically, the access terminal and the access network each calculate an ephemeral public key and send the ephemeral public key to the other. Then, access terminal and access network each calculate a value for SKey based in part on the ephemeral public key received from the other. The access terminal and the access network should both arrive at the same value for SKey.
The second sub-procedure of the DH key-exchange procedure is to verify that, in fact, the access terminal and the access network have calculated the same value for SKey. This second sub-procedure, with several minor differences, is the same process as process 300 of FIG. 3. One difference is that the access network is now the initiator, and the access terminal is the responder. Furthermore, some of the inputs used to create the IR and RR message bits in steps 306 and 316 are different, and the IR and RR hashes generated in steps 308 and 318 are the entire 160-bit SHA-1 hashes, and not the 64 least-significant bits of the SHA-1 hashes. Yet further, the DH key-exchange protocol does not refer to the cryptosync values as Cryptosync and CryptosynchShort, but, instead, as TimeStampLong and TimeStampShort. Lastly, the DH key-exchange procedure does not rely on the generic security protocol to calculate TimeStampLong(IR), TimeStampShort(IR), TimeStampLong(RR), and TimeStampShort(RR), but, instead, calculates those values itself. (From this point forward, the term Cryptosync will refer to both Cryptosync and TimeStampLong, and the term CryptosynchShort will refer to both CryptosynchShort and TimeStampShort.)
Despite these differences, the same equations used by the generic security protocol to calculate the four cryptosync values, e.g., Equations (1), (2), and (3), above, can be used by the DH key-exchange protocol.
When used in the access-channel authentication procedure, Equation (3) requires that the CDMA system time of the access terminal at the moment of cryptosync calculation be less (earlier) than the CDMA system time of the access network at the moment of cryptosync calculation. When used in the DH key-exchange procedure, Equation (3) requires the opposite, i.e., that the access network time be earlier than the access terminal time. Together, these equations would appear to require absolute synchronization between access terminal and access network. Otherwise, one or both of the procedures will fail.
However, the processing and transmission that takes place between those two calculations introduces a measurable delay called the computation and transmission delay CTDelay.
Furthermore, as discussed above, CDMA assumes that the CDMA system times of the access network and BTSs in a typical network are synchronized using the global positioning system (GPS), and that the access terminal is getting its CDMA system time from the BTS. As a result, CDMA system time is tightly synchronized throughout a GPS-enabled CDMA system—so tightly synchronized, in fact, that any discrepancy between the CDMA system times of the access network, BTS, and access terminal is far smaller than CTDelay. Thus, in such GPS-enabled systems, meeting the combined constraints of the two procedures is not a concern.
Another consequence of the assumption of GPS synchronization is that BTS units typically are designed to get their system time from GPS, and not from the access network. However, it sometimes occurs that a BTS temporarily loses GPS signal. It also sometimes occurs that some BTSs never have access to GPS signals, e.g., when a BTS is deployed in a tunnel or subway. In these situations, it is typical for the CDMA system time of the BTS to diverge from the CDMA system time of the access network. Since the access terminal gets its CDMA system time from the BTS, if the BTS is out of sync with the access network, the access terminal will also be out of sync with the access network.
If the difference between the access terminal and access network system times is greater than CTDelay, then either or both of the DH key-exchange procedure or the access-channel authentication procedure will fail. Depending on how the system is configured, those failures may result in access terminal users being unable to access the system.
One possible solution to this dilemma is to modify BTS units so that they get their system time from the access network. However, this can be a costly hardware and software modification.